home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1998 May: Tool Chest / Dev.CD May 98 TC.toast / Tool Chest / Development Kits / • Other Platforms / PCCTS 1.31 / Documentation / UPDAT122.txt < prev    next >
Encoding:
Text File  |  1995-03-10  |  5.5 KB  |  180 lines  |  [TEXT/MPS ]
  1.  
  2.                         PCCTS 1.22 Release Notes
  3.  
  4.                     Active Author for 1.22 Release:
  5.  
  6.                              Terence Parr
  7.                        Parr Research Corporation
  8.                            5517 Pleasant Ave
  9.                          Minneapolis, MN 55419
  10.                              parrt@acm.org
  11.  
  12.                            Other authors:
  13.  
  14.                 Russell Quong, quong@ecn.purdue.edu
  15.                  Will Cohen, cohenw@ecn.purdue.edu
  16.                  Hank Dietz, hankd@ecn.purdue.edu
  17.  
  18.                           August 24, 1994
  19.  
  20.  
  21.     This document describes the 1.22 release of the Purdue Compiler
  22.     Construction Tool Set (PCCTS).  This file describes the changes
  23.     made to PCCTS 1.21 to arrive at PCCTS 1.22.  A number of bug fixes
  24.     were made and the C++ output was cleaned up. The original 1.00
  25.     manual and all release notes are required for a complete
  26.     documentation set for PCCTS.  A book is in the works and the
  27.     papers provided at the ftp site don't hurt.
  28.  
  29.     PCCTS is in the public-domain and can be obtained at
  30.     everest.ee.umn.edu in pub/pccts/1.22.  The newsgroup
  31.     comp.compilers.tools.pccts provides a discussion forum.  To
  32.     receive future release broadcast messages, register yourself by
  33.     sending email to pccts@ecn.purdue.edu with a ``Subject:'' line of
  34.     ``register''.
  35.  
  36.     The authors make no claims that this software will do what you
  37.     want, that this manual is any good, or that the software actually
  38.     works---use PCCTS at your own risk.  Bug reports and/or cheery
  39.     reports of its usefulness are very welcome, however.
  40.  
  41.     The maintenance and support of all PCCTS tools is primarily
  42.     provided by Parr Research Corporation, Minneapolis MN.  Please see
  43.     file PCCTS.FUTURE for more information.  All PCCTS tools currently
  44.     in the public domain will continue to be in the public domain.
  45.  
  46.  
  47. I. NEW FEATURES
  48.  
  49. o    In C++ mode, the normal parser initialization sequence is:
  50.  
  51.     main()
  52.     {
  53.         DLGFileInput in(stdin);
  54.         DLGLexer scan(&in,2000);
  55.         ANTLRTokenBuffer pipe(&scan, k);
  56.         ANTLRToken aToken;
  57.         scan.setToken(&aToken);
  58.         Expr parser(&pipe);
  59.         parser.init();
  60.         parser.e();
  61.     }
  62.  
  63.     As described below in ``C++ CLEANUP'', the new sequence can
  64.     be shortened somewhat to:
  65.  
  66.     main()
  67.     {
  68.         DLGFileInput in(stdin);
  69.         DLGLexer scan(&in);
  70.         ANTLRTokenBuffer pipe(&scan);
  71.         ANTLRToken aToken;
  72.         scan.setToken(&aToken);
  73.         Expr parser(&pipe);
  74.         parser.init();
  75.         parser.e();
  76.     }
  77.  
  78.     where the scanner text buffer size is now 2000 bytes by
  79.     default.  The 'k' value of your parser (determined by the
  80.     ANTLR command line) is set automatically by the parser
  81.     constructor (it sends a message to the token buffer).
  82.  
  83.     This code fragment is pretty common and we now provide
  84.     a template to allow the following:
  85.  
  86.     ... // other normal includes
  87.     #include "PBlackBox.h"          // Standard Black Box for parsing.
  88.     main()
  89.     {
  90.         ParserBlackBox<DLGLexer, Expr, ANTLRToken> parser(stdin);
  91.         parser.parser()->prog();
  92.     }
  93.  
  94.     where parser.parser() returns the instance of 'Expr' created
  95.     by the ParserBlackBox.
  96.  
  97.     This is only experimental.  Feel free to provide feedback or
  98.     suggest a better ``black box'' (e.g., can we do without
  99.     templates).
  100.  
  101.  
  102. II. C++ CLEANUP
  103.  
  104. o    You no longer have to specify the text buffer size for the lexer
  105.     constructor.
  106.  
  107. o    You no longer have to specify the 'k' value for the ANTLRTokenBuffer.
  108.     This is set automatically by the parser to which the token buffer
  109.     is attached.
  110.  
  111. o    Added an ``#ifndef DLGLEXER_H'' gate on the DLGLexer.h file output
  112.     from DLG.  It is also sensitive to the file name; i.e., ``#ifndef
  113.     MYLEXER_H''.
  114.  
  115. o    Function LT(i) now returns an ANTLRTokenBase not an ANTLRLightweightToken
  116.     because it is most token objects will be of a type derived from
  117.     ANTLRTokenBase.  This allows LT(i)->getText() to be specified without
  118.     a type cast on the LTi).
  119.  
  120. o    DLG defined a bunch of constants such as MAX_MODE and all the lexical
  121.     classes that you specified in your grammar.  In 1.21, they were
  122.     #defines.  Now they are const's in the lexer class definition.  As a
  123.     result, multiple lexers with the identical lexical classes can be
  124.     linked together without collision.  ZZSHIFT() became an inline function
  125.     from a macro as well.  To access the constants from outside the
  126.     lexer member functions, you must use the class override; e.g.,
  127.     ``scanner.mode(MyLexer::START)''.
  128.  
  129.  
  130. III. THINGS TO REMEMBER
  131.  
  132. o    Whenever you use k>1 or when you backtrack in C++ mode, you must
  133.     use ANTLRBacktrackingToken or something similar--that is, makeToken()
  134.     must return a stream of unique token objects.  See the 1.21 release
  135.     notes.
  136.  
  137.  
  138. IV. BUGS
  139.  
  140. o    The syntactic predicates at k==1 where broken in 1.20 (I think) so
  141.     that they did not save the lexical text buffer.  This has been
  142.     fixed.
  143.  
  144. o    In testcpp/9/test.g, there should have been a 'public' on the
  145.     inheritance from ASTBase.
  146.  
  147. o    zzline was updated incorrectly in C mode.
  148.  
  149. o    A small bug was found in genmk that resulted in
  150.     outdir/outdir/err.o rather than outdir/err.o.
  151.  
  152. o    zzreal_line was not defined in K&R C mode.
  153.  
  154. o    The following grammar was not analyzed correctly (if you
  155.     can believe it <wink>):
  156.  
  157.     a : A a | ;
  158.  
  159. o    The C++ AST code generation didn't generate the right code
  160.     for
  161.  
  162.     a! : b <<#0=#1;>> ;
  163.  
  164. o    The following didn't result in a correct parser:
  165.  
  166.     a : (A B|B C) | b ;
  167.     b : <<predicate>>? B B;
  168.  
  169. o    When using #tokdefs, redefinition errors were reported in the
  170.     grammar file not the token definition file.
  171.  
  172.  
  173. V. ACKNOWLEDGEMENTS
  174.  
  175. Kurt Fickie at the Army Research Lab suggested the ParserBlackBox class.
  176.  
  177. Thanks to all you folks to tested 1.22 before its release.
  178.  
  179. Thanks as always to the cool folks at NeXT, Inc.
  180.